CM 
O 

o 

Q_ 
LU 




(12) 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 




(11) EP 0 921 655 A2 

EUROPEAN PATENT APPLICATION 



(43) Date of publication: 

09.06.1999 Bulletin 1999/23 



(51) IntCI* H04L 12/18 



(21) Application number: 98308494.8 

(22) Date of filing: 16.10.1998 



(84) Designated Contracting States: 


(72) Inventor: Ooe, Kazuichi, c/o Fujitsu Limited 


AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


Kawasaki-shi, Kanagawa 211-8588 (JP) 


MC NL PT SE 


Designated Extension States: 


(74) Representative: Stebbing, Timothy Charles et al 


AL LT LV MK RO SI 


Haseltine Lake & Co., 




Imperial House, 


(30) Priority: 31.10.1997 JP 29970497 


15-19 Kingsway 


16.09.1998 JP 26158098 


London WC2B 6UD (GB) 


(71) Applicant: FUJITSU LIMITED 




Kawasaki-shi, Kanagawa 211-8588 (JP) 





CM 
< 

m 

CO 



(54) Multicast transmission method 

(57) The present invention relates to a multicast 
transmission method which is capable of realizing a mul- 
ticast function while maintaining the independence of 
multiple nodes (1 ) concurrently with minimizing the traf- 
fic on a communication network (2). In the multicast 
transmission method according to this invention, a data 
transmitting node (NODE#n), in which a multicast trans- 
mission request occurs, adds a multicast address to a 
data send message and then broadcasts the data send 
message plus multicast address to all the nodes (S2), 
while each of the nodes receiving the multicast address 
refers to its own multicast table (3) to decide whether or 
not a multicast address coincident with the received 
multicast address exists in the multicast table (S5). If the 
same multicast address exists, the node (NODE#m) 
makes a request for the transmission of data responding 
to the multicast transmission request toward the data 
transmitting node (NODE#n) through the use of a basic 
communication function, so that the data is transmitted 
from the data transmitting node to the node making the 
data transmission request (S6). This invention is appli- 
cable to communication networks employing a protocol 
such as TCP/IP (Transmission Control Protocol/Internet 
Protocol). 
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Description 

[0001] The present invention relates to a multicast 
transmission method of transmitting data to a plurality 
of nodes (computers, terminals) belonging to a specific s 
group in a communication network based upon a proto- 
col such as TCP/IP (Transmission Control Protocol/In- 
ternet Protocol). 

[0002] In recent years, with the progress of distributed 
processing computer networks, a need to simultaneous- 10 
ly send the same data to a plurality of nodes has in- 
creased for the purpose of improving the processing ef- 
ficiency. In the case of 1-to-N (one-to-many) or N-to-N 
communications (for example, for the execution of an 
application such as a television conference at a plurality i$ 
of nodes), such a situation as to transmit the same data 
to a plurality of nodes grows as compared with one-to- 
one communications. For coping with such a situation, 
computer networks employ a multicast function to con- 
currently forward data to a plurality of nodes pertaining 20 
to a specific group. 

[0003] In general, the Ethernet has been known as the 
typical protocol for the LAN (Local Area Network) con- 
stituting a computer network. In this Ethernet, for real- 
izing the aforesaid multicast function, a group address 2s 
(multicast address) is first set and registered in a com- 
munication driver of each of the nodes pertaining to a 
specific group (multicast group). Subsequently, a node, 
which transmits data, broadcasts transmission data in- 
cluding an address designating the specific group to- 30 
ward all the nodes except the data transmitting node. 
The communication driver of each of the nodes receiv- 
ing the data decides whether or not the address given 
to the transmitted data coincides with an address as- 
signed previously to its own terminal. If the coincidence 35 
between both addresses takes place, the communica- 
tion driver accepts that data, whereas, if no coincidence 
occurs, it abandons the same data. 
[0004]. In addition, Japanese Patent Laid-Open 
(Kokai) No. Hei 5-324545 discloses a technique (a bus 40 
control system for easily realizing the initial connection 
procedure in broadcasting) to designate a receive ter- 
minal group to which data should be transmitted. In the 
technique disclosed in this publication, a group address 
signal line is provided in buses for establishing connec- *s 
tions among all the terminals (nodes), while a group ad- 
dress representative of a group each of the terminals 
belongs to is assigned in advance to that terminal. Fur- 
ther, in transmitting data to only a specific group, a trans- 
mission terminal first broadcasts the group address des- so 
ignating the specific group through the group address 
signal lines to all the terminals other than this transmis- 
sion terminal. Each of the receive terminals receiving . 
the group address checks whether or not the group ad- 
dress transmitted coincides with its own group address $5 
set in advance. The receive terminal, whose group ad- 
dress agrees with the transmitted group address, goes 
into a receive ready condition. Following this, the trans- 



mission terminal side starts to send (broadcast) data to 
the receive terminal belonging to the specific group. 
[0005] However, with the multicast transmission 
method on the Ethernet, the data to be transmitted to 
the nodes belonging to a specific group is broadcasted 
in a state where a group address is given thereto, along 
with the imposition of a burden on the processing on the 
transmission side or on the reception side, the network 
or nodes having no relation also undergo its influence, 
and the traffic in the whole communication network in- 
creases. 

[0006] The multicast communication targets the mul- 
timedia including moving picture data. The moving pic- 
ture data commonly requires the transmission of 30 
scenes (frames) per second, which produces an ex- 
tremely large volume of data. Accordingly, in the case 
of a large volume of data such as such moving picture 
data or voice data being transmitted according to the 
above-mentioned multicast communication method, a 
significant increase in the traffic in the whole communi- 
cation network takes place. 

[0007] Moreover, the technique disclosed in Japa- 
nese Patent Laid-Open (Kokai) No. Hei 5-324545 is de- 
signed such that a transmission terminal designates a 
receive terminal belonging to a specific group to make 
it go into a receive ready condition before the transmis- 
sion terminal side broadcasts data and the terminal be- 
ing in the receive ready condition (that is, the receive 
terminal pertaining to the specific group) receives the 
broadcasted data. However, since the transmission 
from the transmission terminal to the receive terminal 
fully depends upon the broadcasting, the traffic on the 
communication network increases, and the transmis- 
sion of a large volume of data such as moving picture 
data and voice data according to the aforesaid tech- 
nique causes a remarkable increase in the traffic on the 
communication network. 

[0008] An embodiment of the present invention may 
provide a multicast transmission method which is capa- 
ble of realizing a multicast function while minimizing the 
traffic on a communication network concurrently with 
maintaining the independence of each of nodes through 
the use of the existing communication primitive such as 
the SEND-GET which will concretely be described here- 
in later. 

[0009] For this purpose, in accordance with the 
present invention, there is provided a multicast trans- 
mission method of, in a system in which a plurality of 
nodes are connected through a communication network 
to each other to be mutually communicable, making a 
data transmitting node of the plurality of nodes, in which 
a multicast transmission request occurs, transmit data 
to a node of said plurality of nodes, which belongs to a 
specific group through the communication network, 
wherein each of the plurality of nodes includes a com- 
munication driver having, as a basic communicating 
function, a function to issue and send a data send mes- 
sage for sending data to a receive buffer defined in ad- 
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vance in a data receiving node, a data get (acquisition) 
command for designating data in a memory of a given 
node to make a request for a transmission of the data 
to the node, and a data send command for designating 
a memory address in a data receiving node to transmit 
data, and when a node belongs to the specific group, a 
multicast address designating the specific group is set 
and registered in a multicast table included in the node 
belonging to the specific group, and the data transmit- 
ting node broadcasts the data send message, to which 
the multicast address designating the specific group is 
added, through the communication network to all the 
plurality of nodes while each of the nodes receiving the 
multicast address through the data send message re- 
fers to its own multicast table to decide whether or not 
a multicast address coincident with the received multi- 
cast address exists within the multicast table, and a 
node, in which the same multicast address exists within 
the multicast table, serves as a data receiving node to 
make a request for a transmission of the data corre- 
sponding to the multicast transmission request to the 
data transmitting node through the use of the basic com- 
munication function so that the data is transmitted from 
the data transmitting node to the node serving as the 
data receiving node. 

[0010] At this time, it is also appropriate that the data 
receiving node that the multicast address exists within 
the multicast table issues and sends the data get com- 
mand, the data send message or the data send com- 
mand to the data transmitting node to make a request 
for the transmission of the data corresponding to the 
multicast transmission request so that the data is trans- 
mitted from the data transmitting node to the data re- 
ceiving node. 

[0011] Furthermore, it is also appropriate, that the 
node in which the multicast address does not exist within 
the multicast table issues and sends the data send com- 
mand, the data get command or the data send message 
to the data transmitting node to inform the data trans- 
mitting node of the fact that the transmission of the data 
corresponding to the multicast transmission request is 
unnecessary. On the other hand, it is also acceptable 
that the node in which the multicast address does not 
exist within the multicast table immediately terminates 
its processing without informing the data transmitting 
node of the fact that the transmission of the data re- 
sponding to the multicast transmission request is unnec- 
essary. 

[0012] With a multicast transmission method embod- 
ying this invention, only the transmission of a small 
quantity of data at the multicast address is made in the 
broadcasting way and the transmission of the multicast 
data is done in a one-tOrone relation between the data 
transmitting node and each of the nodes being the target 
of the multicast transmission, thus readily accomplish- 
ing the multicast function between the nodes while min- 
imizing the traffic on the communication network. 
[0013] Still further, since the decision as to whether or 



not each of the nodes is the target of the multicast trans- 
mission is made through the use of the multicast table, 
it is possible to realize the multicast function while main- 

( taining the independence of each of the nodes. 

s [0014] Reference is made, by way of example, to the 
accompanying drawings in which: - 

Figs. 1 A and 1 B are flow charts useful for explaining 
a multicast transmission method according to an 

10 embodiment of the present invention; 

Fig. 2 is a block diagram showing an arrangement 
of a communication network system to which the 
multicast transmission method of the embodiment 
of this invention is applied, and also, is an illustration 

15 for describing an operation of the same communi- 
cation network system; 

Fig. 3 is a block diagram showing a principal portion 
of the communication network system according to 
this embodiment for describing a first data transmis- 

20 sion request method; 

Fig. 4 is a block diagram showing a principal portion 
of the communication network system according to 
this embodiment for describing a second data trans- 
mission request method; 

25 Fig. 5 is a block diagram showing a principal portion 
of the communication network system according to 
this embodiment for describing a third data trans- 
mission request method; 

Fig. 6 is a block diagram showing a principal portion 

30 of the communication network system according to 
this embodiment for explaining a first data transmis- 
sion cancel notifying method; 
Fig. 7 is a block diagram showing a principal portion 
of the communication network system according to 

35 this embodiment for explaining a second data trans- 
mission cancel notifying method; 
Fig. 8 is a block diagram showing a principal portion 
of the communication network system according to 
this embodiment for explaining a third data trans- 

40 mission cancel notifying method; 

Fig. 9 is a block diagram showing a principal portion 
of the communication network system according to 
this embodiment for explaining a method to be tak- 
en in the case of no notification of data transmission 

45 cancel; 

Fig. 10 is a block diagram showing a principal por- 
tion of a common communication network system 
for explaining a PUT command and a GET com- 
mand; and 

50 Fig. 11 is a block diagram showing a principal por- 
tion of a common communication network system 
for explaining a communication method based upon 
a SEND-GET 

55 [0015] An embodiment of the present invention will be 
described hereinbelow with reference to the drawings. 
[0016] In general, in a high-speed communication 
network (for example, AP-Net) making a communication 
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speed above 1600 Mbps, a PUT command or a GET 
command is put to use for the data copy (memory copy) 
between nodes through the communication network. 
[0017] In this case, as shown in Fig. 10, a node #N 
forwards the data at an address XXX in amemory 1 00-N 
to a node #M, the PUT command (data send command) 
is issued from the node #N to the node #M. That is, in 
a manner that the node #N designates an ID (in this ex- 
ample, M) of the data receiving node #M being the des- 
tination of the data and a data-copied address YYY in a 
memory 1 00-M of the node #M and issues the PUT com- 
mand, the data laying at the address XXX in the memory 
1 00-N of the node #N transferred and copied through a 
communication network 200 into the address YYY in the 
memory 100-M of the node #M. 

[0018] On the other hand, as shown in the same illus- 
tration, when the node #N gets (copies) the data at an 
address WWW in the memory 100-M of the node #M, 
the GET command (data get command) is issued from 
the node #N to the node #M. That is, in a manner that 
the node #N designates an ID (in this example, M) of 
the node #M retaining the target data and the address 
WWW designating the target data and issue the GET 
command, the data existing at the address WWW in the 
memory 100-M of the node #M is copied through the 
communication network 200 into an address 777 in the 
memory 100-N of the node #N. * 

[0019] Usually, the aforesaid GET command is used 
in the form of a combination with a SEND message as 
shown in Fig. 11 , and a communication mode based up- 
on this combination is called SEND-GET. Besides, the 
SEND message (data send message) is used when the 
data of a data transmitting node is forwarded to a receive 
buffer defined in advance by a data receiving node. 
[0020] Furthermore, in the communication mode 
based on the SEND-GET, as shown in Fig. 11, the SEND 
message retaining the address XXX of the transmission 
data on the memory (SEND DATA BUFFER) 1 00-N and 
the size S of that data is transmitted from the data trans- 
mitting node #N to the data receiving node #M. 
[0021] In the node #M, the SEND message taken from 
the node #N through the communication network 200 is 
once stored in a receive buffer (not shown). Subse- 
quently, after the contents of the SEND message are 
deciphered or decoded in a communication driver (not 
shown), a data write area according to the size S is se- 
cured on the memory (GET DATA BUFFER) 100-M, be- 
fore the GET command is issued to the node #N so that 
the data at the address XXX in the memory 100-N is 
forwarded to the node #M. The data sent from the node 
#N through the communication network 200 in response 
to this GET command is written into the area of the des- 
ignated address (the aforesaid data write area) in the 
memory 100-M of the node #M. 

[0022] Through the use of the communication driver 
employing the SEND-GET or the PUT command as a 
basic communication function, the data transmitting 
node can designate an arbitrary address in a memory 



to directly transmit data to that address, thus enabling 
the effective execution of data copy between nodes to 
enhance the communication performance and, further, 
facilitating the buffer management in each of the nodes. 

5 [0023] This embodiment is for developing and estab- 
lishing a method of realizing a multicast function by uti- 
lizing the existing basic communication function issuing 
a SEND message, a GET command and a PUT com- 
mand, and this method can minimize the traffic in the 

10 whole communication network concurrently with main- 
taining the independence of each of the nodes. 
[0024] Fig. 2 is a block diagram showing an arrange- 
ment of a communication network system to which a 
multicast transmission method according to the embod- 

15 iment of this invention is applied, and is also an illustra- 
tion available for explaining an operation of this commu- 
nication network system. In the communication network 
system according to this embodiment shown in Fig. 2, 
a plurality of nodes 1 (#0 to #N) are connected through 

20 a communication network (for example, AP-Net) 2 us- 
ing, for example, TCP/IP to each other to be communi- 
cable mutually 

[0025] Each of the nodes 1 is equipped with a com- 
munication driver (data link driver; for example, AP-Net 
25 driver) la for directly giving and taking signals to/from 
the communication network 2 to accomplish the trans- 
mission/reception of data. 

[0026] This communication driver la is employed as a 
basic communication function (which will sometimes be 

30 referred hereinafter to as a communication primitive) in- 
cluding a function (including a communication mode 
based on SEND-GET) to issue and send the SEND 
message, the GET command and the PUT command 
mentioned before with reference to Figs. 1 0 and 11 . As 

35 mentioned previously, the SEND message (data send 
message) is for transmitting data to a receive buffer de- 
fined in advance by the data transmitting node, and the 
GET command (data get command) is for designating 
data in a memory (send data buffer 4 which will be de- 

40 scribed herein later) of a given node to make a request 
for the transmission of that data to the corresponding 
node, and further, the PUT command (data send com- 
mand) is for designating a memory address in a receiv- 
ing (destination) node and for transmitting data. 

45 [0027] In addition, as shown in Figs. 3 to 9, each of 
the nodes 1 is provided with a multicast table 3, a send 
(transmission) data buffer 4, a receive/get (acquisition) 
data buffer 5 and a multicast transmission table 6. In 
Figs. 3 to 9, a data transmitting node 1 is shown as a 

50 node #n while one of data receiving nodes 1 pertaining 
to a multicast group is shown as a node #m, and only 
components needed at the transmission in each mode 
are illustrated in the node #n- while only components 
necessary at the reception in each mode are illustrated 

55 in the node #m. Further, in Figs. 3 to 9, the communica- 
tion driver 1a of the nodes 1 are omitted from the illus- 
tration. 

[0028] In this case, the multicast table 3 is made in 
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such a manner that, when a node 1 possessing this mul- 
ticast table 3 belongs to a multicast group (specific 
group), a multicast address (group address) of the group 
it belongs to is set and registered beforehand. Inciden- 
tally, in a multicast transmission based upon the TCP/ s 
IP, of IP addresses each comprising 32 bits, an address 
whose leading four bits is "1 11 0° is recognized as a mul- 
ticast address. That is, the range of 224.0.0.0 to 
239.255.255.255 is made to be allocated to the multi- 
cast addresses. io 
[0029] The send data buffer (memory) 4 stores data 
(for example, multicast data) to be transmitted, while the 
receive/get data buffer (memory) 5 stores data received 
or acquired from a data transmitting node. 
[0030] The multicast transmission table 6 is made in is 
such a manner that a flag (YES/NO) for recognizing a 
node (data receiving node) which is the target of the mul- 
ticast transmission is set at every node 1 other than its 
own node, with that flag being set by a PUT command 
or a SEND message from a data receiving node as will 20 
be mentioned later. 

[0031] The multicast table 3, the send data buffer 4, 
the receive/get data buffer 5 and the multicast transmis- 
sion table 6 are incorporated into or provided in associ- 
ation with the communication driver la of each of the 25 
nodes 1 ; 

[0032] Secondly, referring to Figs. 1 to 9, a description 
will be given hereinbelow of a multicast transmission 
method for use in the communication network system 
thus arranged according to this embodiment. 30 
[0033] The description will start with a basic proce- 
dure of the multicast transmission method according to 
this embodiment, that is, a basic operation for the mul- 
ticast transmission by the communication driver la of 
each of the nodes 1 , with reference to the flow charts 35 
shown in Figs. 1 A and 1B in view of Fig. 2. 
[0034] Fig. 1 A is *a flow chart (steps SO to S3 and S31 ) 
available for describing a basic transmission processing 
procedure to be conducted in each of the nodes 1 . As 
illustrated in Fig. 1A, the communication driver 1a of 40 
each of the nodes 1 always decides whether a transmis- 
sion request occurs or not (step SO), and if it occurs 
(YES route from step SO), checks whether or not the 
transmission request signifies a multicast transmission 
request (step S1). 45 
[0035] When receiving the multicast transmission re- 
quest (YES route from step S1), the communication 
driver la adds a multicast address corresponding to that 
multicast transmission request to a SEND message and 
broadcasts the SEND message plus multicast address so 
to all the nodes 1 (step S2; see a thin solid line drawn 
arrow Al "SEND MESSAGE WITH MULTICAST AD- 
DRESS" in Fig. 2). At this time, the data volume of the 
SEND message with the multicast address is consider- 
ably small, with the result that the traffic on the commu- ss 
nication network 2 hardly undergoes the influence of the 
broadcast of the SEND message. 
[0036] Furthermore, the communication driver la 



transmits multicast data to the node (node pertaining to 
a multicast group; data receiving node) 1 which issues 
the request for the data transmission in response to the 
broadcasted SEND message (step S3). 
[0037] On the other hand, if the answer of the step SI 
shows that the transmission request does not assume 
the multicast transmission request (NO route from step 
S1 ), the communication driver la conducts the transmis- 
sion processing in answer to that transmission request 
(step S31). 

[0038] Meanwhile, Fig. 1 B is a flow chart (steps S32, 
S4 to S7 and S41) useful for explaining a basic trans- 
mission processing procedure to be done in each of the 
nodes 1 . As shown in Fig. 1 B, the communication driver 
la of each of the nodes 1 always decides whether data 
arrives (is received) or not (step S32), and if the data 
comes (YES route from step S32), checks whether or 
not that data is a SEND message with a multicast ad- 
dress (step S4). 

[0039] When the node 1 (communication driver la) re- 
ceives the SEND message with the multicast address 
(YES route from step S4), the communication driver la 
refers to the multicast table 3 (see Figs. 3 to 9) to com- 
pare the multicast address added to the SEND message 
it receives with a set address within the multicast table 
3 for deciding whether or not that multicast address ex- 
ists within the multicast table 3 (step S5). 
[0040] If that multicast address exists within the mul- 
ticast table 3 (YES route from step S5), the communi- 
cation driver la issues a request for the transmission of 
multicast data (data responding to a multicast transmis- 
sion request a data transmitting node issues) to a data 
transmitting node transmitting the SEND message 
through the use of a communication primitive (the gen- 
eration and delivery of a GET command, a SEND mes- 
sage or a PUT command) (see a dotted line drawn arrow 
A2 "REQUEST MULTICAST DATA" to make the data 
transmitting node transmit the data to its own node (step 
S6). The data transmission request method using the 
communication primitive (a GET command, a SEND 
message or a PUT command) in this step S6 will be de- 
scribed herein later with reference to Figs. 3 to 5. 
[0041] On the other hand, if the multicast address 
does not exist within the multicast table 3 (NO route from 
step S5), the communication driver la informs the data 
transmitting node transmitting the SEND message of 
the fact that the transmission of the multicast data is un- 
necessary, through the use of the communication prim- 
itive (the generation and delivery of a PUT command, a 
GET command or a SEND message) (step S7; see a 
dashed line drawn arrow A3 "CANCEL MULITICAST 
DATA"). The data transmission cancel notifying method 
using the communication primitive (a PUT command, a 
GET command or a SEND message) in this step S7 will 
be described herein later with reference to Figs. 6 to 8. 
[0042] Besides, as will be mentioned herein later, the 
communication driver la can also immediately terminate 
its processing without informing of no need for the data 
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transmission. In this case, the step S7is omissible. 
[0043] Furthermore, if the decision of the step S4 in- 
dicates that the reception data is not the SEND message 
with the multicast address (NO route from step S4), the 
communication driver la pertinently processes the data 
it receives in accordance with its contents (step S41 ). 
[0044] Referring to Fig. 2, a description will be taken 
hereinbelow of a series of multicast transmission oper- 
ations according to this embodiment. As indicated by the 
thin solid line drawn arrow A1, a data transmitting node 
#0 in which a multicast transmission request occurs 
adds a multicast address to a SEND message and 
broadcasts the SEND message plus multicast address 
to nodes #1 to #N through the processing of the step S2 
in Fig. 1 A 

[0045] Each of the nodes #i (/= 1 to N) receiving the 
multicast address compares that multicast address with 
a set address within the multicast table 3 through the 
processing of the step S5 in Fig. 1 B to check whether 
or not that multicast address exists within the multicast 
table 3. 

[0046] The node #1 in which the multicast address ex- 
ists within its multicast table 3 makes a request for the 
transmission of the corresponding multicast data toward 
the data transmitting node #0 by the use of a communi- 
cation primitive (a GET command, a SEND message or 
a PUT command) through the processing of the step S6 
in Fig. 1 B as indicated by the dotted line drawn arrow 
A2, so that the data transmitting node #0 forwards the 
multicast data to the node #1. 

[0047] On the other hand, the node #2 or #N in which 
the multicast address does not exist within its multicast 
table 3 informs the data transmitting node #0 of the fact 
of no need for the transmission of the multicast data by 
the use of a communication primitive (a PUT command, 
a GET command or a SEND message) through the 
processing of the step S7 in Fig. 1 B as indicated by the 
dashed line drawn arrow A3. 

[0048] Thus, it is possible to accomplish the multicast 
transmission from the data transmitting node #0, in 
which the multicast transmission request occurs, to the 
data receiving node #1 belonging to the multicast group 
in answer to the multicast transmission request. 
[0049] Moreover, referring to Figs. 3 to 5, a description 
will be made hereinbelow of data transmission request 
methods (the processing of the step S6 in Fig. 1 B) using 
a GET command, a SEND message or a PUT command 
which constitutes a communication primitive. In each of 
the examples shown in Figs. 3 to 5, let it be assumed 
that a data transmitting node #n attaches a multicast ad- 
dress, for example, "224.0.0.2" to a SEND message to 
broadcast the SEND message plus multicast address 
and this address "224.0. 0.2" exists within the multicast 
table 3 of a node #m. 

[0050] In a first data transmission request method 
shown in Fig. 3, the node #m issues a GET command 
toward the data transmitting node #n to make a request 
for the transmission of multicast data, so that the com- 



munication driver la (see Fig. 2) causes the multicast 
data in the send data buffer 4 of the data transmitting 
node #n to be forwarded through the communication 
network 2 to the node #m and to be put at a designated 
s address in the receive/get data buffer 5 of the node #m. 
[0051] Furthermore, in a second data transmission re- 
quest method shown in Fig. 4, the node #m sends a 
SEND message with a multicast data transmission re- 
quest ("REQUEST MULTICAST DATA") to the data 

10 transmitting node #n to make a request for the transmis- 
sion of multicast-data thereto, whereupon the commu- 
nication driver 1a (see Fig. 2), after deciphering that 
message, causes the multicast data in the send data 
buffer 4 of the data transmitting node #n to be forwarded 

is through the communication network 2 to the node #m. 
[0052] Still further, in a third data transmission request 
method, the node #m issues a PUT command to the da- 
ta transmitting node #n for making a request for the 
transmission of the multicast data, whereupon "YES" 

20 (flag ON) is put in a column pertinent to the node #m in 
the multicast transmission table 6 of the data transmit- 
ting node #n. Referring to the multicast transmission ta- 
ble 6 to confirm that the flag of the node #m is in the ON 
state, if so, the communication driver la (see Fig. 2) of 

2S the data transmitting node #n transmits the multicast da- 
ta in the send data buffer 4 through the communication 
network 2 to the node #m. 

[0053] Meanwhile, the data transmitting node 1, 
which broadcasts a SEND message with a multicast ad- 
30 dress, expects a response from all the nodes 1 forming 
the broadcasting targets. Thus, in this embodiment, as 
mentioned previously, the node(s) 1 in which the multi- 
cast address does not exist within its multicast table 3 
also informs the data transmitting node 1 of the fact that 
the transmission of the multicast data is unnecessary 
through the use of a PUT command, a GET command 
or a SEND message. 

[0054] Moreover, referring to Figs. 6 to 9, a description 
will be made hereinbelow of data transmission cancel 

40 notifying methods (the processing of the step S7 in Fig. 
1 B) using a PUT command, a GET command or a SEND 
message which constitutes a communication primitive, 
and of the case of no notification of the data transmis- 
sion cancel. In. each of the examples shown in Figs. 6 

45 to 9, let it be assumed that the data transmitting node 
#n adds a multicast address, for example, "224.0.0. 2" 
to a SEND message to broadcast the SEND message 
plus multicast address and that address does not coin- 
cide with an address "224.0.0.3" registered in the mul- . 

so ticast table 3 of the node #m, that is, the address 
"224.0.0.2" does not exist within the multicast table 3 of 
the node #m. 

[0055] In a first data transmission cancel notifying 
method shown in Fig. 6, the node #m issues a PUT com- 
ss mand to the data transmitting node #n to inform it of the 
fact that the transmission of the multicast data is unnec- 
essary so that "NO"(flag OFF) is placed in a column for 
the node #m in the multicast transmission table 6 of the 
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data transmitting node #n. The communication driver la 
(see Fig. 2) of the data transmitting node #n refers to 
the multicast transmission table 6, and if the flag of the 
node #m is the OFF state, inhibits the transmission of 
the multicast data to the node #m. s 
[0056] In a second data transmission cancel notifying 
method shown in Fig. 7, the node #m issues a GET com- 
mand to the data transmitting node #n to inform it of the 
fact that the transmission of the multicast data is unnec- 
essary (the information is made through the updating of 10 
a GET command completion flag) so that B NO"(fiag 
OFF) is placed in a column for the node #m in the mul- 
ticast transmission table 6 of the data transmitting node 
#n. The communication driver la (see Fig. 2) of the data 
transmitting node #n refers to the multicast transmission is 
table 6, and if the flag of the node #m is the OFF state, 
inhibits the transmission of the multicast data to the 
node #m. 

[0057] In a third data transmission cancel notifying 
method shown in Fig. 8, the node #m issues a SEND 20 
message with multicast data transmission non-require- 
ment information ("CANCEL MULTICAST DATA") to the 
data transmitting node #n to inform it of the fact that the 
transmission of the multicast data is unnecessary. The 
communication driver la (see Fig. 2), decoding that mes- 25 
sage, does not transmit the multicast data to the node 
#m. 

[0058] Besides, it is also appropriate that, as shown 
in Fig. 9, the node #m immediately terminates the 
processing without issuing the data transmission cancel 30 
notification to the data transmitting node #n. However, 
in this case, since the data transmitting node #n side 
warts for the response from the node #m, there is a need 
to add an arrangement made such that a timer is pro- 
vided so that, when there is no response from the node 35 
#m for a given period of time, the data transmitting node 
#n side assumes that the transmission of the multicast 
data to the node #m is unnecessary. 
[0059] As described above, in the multicast transmis- 
sion method according to an embodiment of this inven- *o 
tion, a data transmitting node 1 in which a multicast 
transmission request occurs adds a multicast address 
to a SEND message and broadcasts the SEND mes- 
sage plus multicast address to all the nodes, and only 
the node(s) 1 having a previously set address coincident 45 
with the multicast address issues and sends a GET 
command, a SEND message or a PUT command to ac- 
tively make a request for the transmission of the multi- 
cast data to the data transmitting node 1 , and therefore, 
the multicast data transmission is achieved in one-to- so 
one relation between the data transmitting node 1 and 
each of the nodes being the target of the multicast trans- 
mission. At this time, since the broadcast of the SEND 
message hardly affects the traffic on the communication 
network 2 as mentioned before, it is possible to realize 55 
a multicast function among the nodes 1 while minimizing 
the traffic on the communication network 2. 
[0060] In addition, according to this embodiment, 



since the decision as to which the target of the multicast 
transmission is depends upon the use of the multicast 
table 3 in each of the nodes 1 , it is possible to realize a 
multicast function concurrently with maintaining the in- • 
dependence of each of the nodes. 
[0061] It should be understood that the present inven- 
tion is not limited to the above-described embodiment, 
and that it is intended to cover all changes and modifi- 
cations of the embodiment of the invention herein which 
do not constitute departures from the scope of the in- 
vention. 

[0062] For instance, although, in the above-described 
embodiment, this invention is applied to a communica- 
tion network based upon TCP/IP, this invention is not 
limited to this, but is likewise applicable to any commu- 
nication network employing a protocol defining a SEND 
message, a GET command and a PUT command, and 
in this case, the same effects are obtainable. 



Claims 

1. A multicast transmission method of, in a system in 
which a plurality of nodes (1 ) are connected through 
a communication network (2) to each other to be 
mutually communicable, making a data transmitting 
node of said plurality of nodes (1), in which a mul- 
ticast transmission request occurs, transmit data to 
a node of said plurality of nodes (1 ), which belongs 
to a specific group, through said communication 
network (2), characterized in that 

each of said plurality of nodes (1) includes a 
communication driver (la) having, as a basic com- 
municating function, a function to issue and send a 
data send message for sending data to a receive 
buffer defined in advance in a data receiving node, 
a data get command for designating data in a mem- 
ory of a given node to make a request for a trans- 
mission of said data to the given node, and a data 
send command for designating a memory address 
in a data receiving node to transmit data, and when 
a node belongs to said specific group, a multicast 
address designating said specific group is set and 
registered in a multicast table (3) included in the 
node belonging to said specific group, and said data 
transmitting node broadcasts said data send mes- 
sage, to which said multicast address designating 
said specific group is added, through said commu- 
nication network (2) to all said plurality of nodes (1) 
while each of said nodes (1 ) receiving said multicast 
address through said data send message refers to 
its own multicast table (3) to decide whether or not 
a multicast address coincident with the received 
multicast address exists within said multicast table 
(3), and a node, in which the same multicast ad- 
dress exists within said multicast table (3), serves 
as a data receiving node to make a request for a 
transmission of data corresponding to said multi- 
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cast transmission request to said data transmitting 
node through the use of said basic communication 
function so that said data is transmitted from said 
data transmitting node to the node serving as said 
data receiving node. s 

A multicast transmission method as defined in claim 
1 , characterized in that said data receiving node, in 
which said multicast address exists within said mul- 
ticast table (3), issues said data get command to io 
said data transmitting node to make a request for 
transmission of said data corresponding to said 
multicast transmission request so that said data is 
transmitted from said data transmitting node to said 
data receiving node. ' 15 

A multicast transmission method as defined in claim 
1 , characterized in that said data receiving node, in 
which said multicast address exists within said mul- 
ticast table (3), sends said data send message to 20 
said data transmitting node to make a request for 
transmission of said data corresponding to said 
multicast transmission request so that said data is 
transmitted from said data transmitting node to said 
data receiving node. 25 



ta transmitting node to inform said data transmitting 
node of the fact that transmission of said data cor- 
responding to said multicast transmission request 
is unnecessary. 

8. A multicast transmission method as defined in claim 
1, 2, 3, or 4, wherein said node, in which said mul- 
ticast address does not exist within said multicast 
table (3), immediately terminates its processing 
without informing said data transmitting node of the 
fact that transmission of said data corresponding to 
said multicast transmission request is unnecessary. 



A multicasttransmission method as defined in claim 
1 , characterized in that said data receiving node, in 
which said multicast address exists within said mul- 
ticast table (3), issues said data send command to 30 
said data transmitting node to make a request for 
transmission of said data corresponding to said 
multicast transmission request so that said data is 
transmitted from said data transmitting node to said 
data receiving node. 35 



A multicasttransmission method as defined in claim 
1, 2, 3, or 4 r wherein said node, in which said mul- 
ticast address does not exist within said multicast 
table (3), issues said data send command to said 40 
data transmitting node to inform said data transmit- 
ting node of the fact that transmission of said data 
corresponding to said multicast transmission re- 
quest is unnecessary. 

4S 

A multicast transmission method as defined in claim 
1, 2, 3, or 4, wherein said node, in which said mul- 
ticast address does not exist within said multicast 
table (3), issues said data get command to said data 
transmitting node to inform said data transmitting so 
node of the fact that transmission of said data cor- 
responding to said multicast transmission request 
is unnecessary. 

A multicast transmission method as defined in claim 55 
1 , 2, 3, or 4, wherein said node, in which said mul- 
ticast address does not exist within said multicast 
table (3), sends said data send message to said da- 
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FIG. 3 
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FIG. 8 
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FIG. 10 



NODE xtN 



NODE #M 



MEMORY 



ADDRESS 
XXX 



ZZZ 



MEMORY 



ADDRESS 
YYY 



PUT NODE =M, ADDRESS=YYY 

-I =U 

GET NODE= M, ADDRESS = WWW 



X 



i 

100-N 




200 



19 



EP 0 921 655 A2 



FIG. II 



N0DE-2N 




NODE &M 



100- N 



GET DATA 


BUFFER 
















\ t <- 

t f 






1 I 
1 I 






1 t 
i I 







\ GET NODE = N, ADDRESS=XXX / i 

v - , 

S 



SEND MESSAGE WITH DATA ADDRESS=XXX a SIZE = S 



ZE = S \ 



ZOO 



20 



(19) 



3 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



01) 



EP 0 921 655 A3 



(12) 



EUROPEAN PATENT APPLICATION 



(88) Date of publication A3: 


(51) IntCI 6: H04L 12/18 


16.06.1999 Bulletin 1999/24 


(43) Date of publication A2: 




09.06.1999 Bulletin 1999/23 




(21) Application number: 98308494.8 




(22) Date of filing: 16.10.1998 




Desionated Contraetina States* 


(72} Inventor Ooe. Kazuichi c/o Fuiitsu Limited 


AT BE CH CY DE DK ES F! FR GB GR IE IT LI LU 


Kawasaki-shi, Kanagawa 21 1 -8588 (JP) 


MC NL PT SE 




Designated Extension States: 


(74) Representative: St ebbing, Timothy Charles et al 


AL LT LV MK RO SI 


Haseltine Lake & Co., 




Imperial House, 


(30) Priority: 31.10.1997 JP 29970497 


15-19 King sway 


16.09.1998 JP 26158098 


London WC2B 6UD (GB) 


(71) Applicant: FUJITSU LIMITED 




Kawasaki-shi, Kanagawa 211-8588 (JP) 





(54) Multicast transmission method 



CO 
< 

m 
in 

CD 



(57) The present invention relates to a multicast 
transmission method which is capable of realizing a mul- 
ticast function while maintaining the independence of 
multiple nodes (1) concurrently with minimizing the traf- 
fic on a communication network (2). In the multicast 
transmission method according to this invention, a data 
transmitting node (NODE#n), in which a multicast trans- 
mission request occurs, adds a multicast address to a 
data send message and then broadcasts the data send 
message plus multicast address to all the nodes (S2), 
while each of the nodes receiving the multicastaddress 
refers to its own multicast table (3) to decide whether or 
not a multicast address coincident with the received 
multicastaddress exists in the multicast table (S5). If the 
same multicast address exists, the node (NODE#m) 
makes a request for the transmission of data responding 
to the multicast transmission request toward the data 
transmitting node (NODE#n) through the use of a basic 
communication function, so that the data is transmitted 
from the data transmitting node to the node making the 
data transmission request (S6). This invention is appli- 
cable to communication networks employing a protocol 
such as TCP/IP (Transmission Control Protocol/Internet 
Protocol). 
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